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(57) A method and system for processing an enter- 
prise's incoming customer communications on the basis 
of the enterprise's business objectives. An enterprise 
service balancer distributes work based upon enterprise 
resources and immediate resource availability. The en- 
terprise service balancer provides an instantaneous 
best possible service for a customer communication (a 
g., a call) by matching the customer communication with 
the most appropriate available resource in the enter- 
prise, as a whole, in accordance with the enterprise's 
definition of best service. The enterprise service balanc- 
er may refrain from moving media for a customer com- 
munication to an identified resource until after determin- 
ing that the identified resource accepts the customer 
communication for further processing. The enterprise 



service balancer looks for an enterprise resource having 
a specific skills set when the enterprise receives a cus- 
tomer communication requiring the specific skills set. 
The enterprise service balancer operates in conjunction 
with enterprise resources as diverse as call center 
agents, back office agents, and robotic call processing 
applications. The back office agents, such as technical 
staff members, represent persons who do not typically 
handle customer communications. The robotic call 
processing system may operate in conjunction with an 
interactive voice response ("IVR") system or other such 
robotic system appropriate for the communications me- 
dia. The enterprise service balancer may process cus- 
tomer communications arriving via media such as te- 
lephony, e-mail, video kiosk, and an internet. 
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Description 

TECHNICAL FIELD 

[0001] The invention relates generally to the process- 
ing and distribution of customer communications within 
an enterprise and, more particularly, to analyzing and 
processing each customer communication entering the 
enterprise to provide communication processing con- 
sistent with enterprise business objectives. 

BACKGROUND OF THE INVENTION 

[0002] A business enterprise, or simply "enterprise," 
may utilize one or more call centers to handle inbound 
and outbound customer calls. A typical call center in- 
cludes a number of agents who field inbound telephone 
calls and place outbound telephone calls. Call centertel- 
ephone calls frequently have associated data, such as 
customer information that the agents utilize in process- 
ing the calls. The call center's communication system 
may organize the agents into groups, known as skill/split 
hunt groups, based on their skills and qualifications. 
[0003] A conventional call center typically comprises 
either an automatic call distributor ("ACD") or private 
branch exchange ("PBX") that receives incoming calls 
through a public switched telephone network ("PSTN") 
and routes the calls to a skill/split hunt group, rather than 
to a specific agent. Agents are associated with these 
skill/split hunt groups to receive incoming calls. An ACD 
typically contains a superset of the functions provided 
by a PBX. The ACD/PBX typically queues incoming 
calls to one or more skill/split hunt groups with available 
agents on the basis of statistical information that these 
skill/split groups satisfy an objective level of service. An 
objective level of service might be "calls answered on 
the average in 10 seconds" or "90% of calls are an- 
swered in 20 seconds." When multiple agents are avail- 
able to handle a call, typically they will deliver the call to 
the agent who has been idle - waiting for a next call - 
the longest period of time. Other criteria for agent selec- 
tion are also used. The agents typically process custom- 
er calls utilizing either specialized telephones, known as 
ACD/PBX feature phones, that interface with a specific 
ACD/PBX or utilize software-controlled telephony appli- 
cations ("softphones") that can coexist with a proprietary 
ACD/PBX feature phone or can utilize telephone sets 
not necessarily designed for the call center's particular 
ACD/PBX. Softphones provide a less expensive means 
for attaining many of the capabilities of an ACD/PBXfea- 
ture phone while using only software in combination with 
a "plain-old-telephone set" ("POTS"). 
[0004] Call center agents typically have access to 
customer data to facilitate call processing. For example, 
a call center agent may utilize a graphical user interface 
("GUI") program that provides calling scripts and access 
to a customer database. In a softphone environment, 
the GUI program may also control telephony functions. 



While interacting with a caller, the agent uses hot keys 
or an electronic mouse to select telephony functions on 
a workstation screen. A hot key is a keystroke or com- 
bination of keystrokes that sends a command to a com- 

s puting system that processes the agent's commands. 
[0005] Figure 1 illustrates a conventional softphone- 
configured call center 130. In the softphone call center 
130, an ACD 102 interfaces between the customer tel- 
ephone call 1 00 and an agent telephone 1 08 in an agent 

10 workstation 1 20. The softphone call center 1 30 will com- 
prise multiple agent workstations 120 having multiple 
agent telephones 108. Customers typically place tele- 
phone calls to the agent telephones 108 via the PSTN 
101. When a customer telephone call 1 00 arrives at the 

15 ACD 1 02, an ACD route point 1 03 receives the call. The 
ACD 102 routes incoming calls through the ACD route 
point 1 03 which typically comprises a phone number (e. 
g., a directory number ("DN")) in the numbering plan of 
the ACD 102 that works in conjunction with a routing 

20 program 104 that provides a call-handling instructions 
script. An ACD vector 105, typically a computer pro- 
gram, controls the routing program 104 to enable cus- 
tomized call processing specifications in the ACD 102. 
The routing program 1 04 tells the ACD's call processing 

25 software how to treat the customer call 100. The routing 
program 104 typically includes at least one announce- 
ment and at least one queue statement. The ACD vector 
105 and the routing program 104 may be combined in 
some conventional ACDs. The queue statement directs 

30 the call to a specific ACD skill/split hunt group 1 06 based 
on the assumption that the skill/hunt group 1 06 provides 
the best service to the incoming caller. The ACD skill/ 
split hunt group 106 has a single phone number, a Pilot 
Directory Number ("Pilot DN") 107, that subsequently 

35 directs the client telephone call to one of the available 
agenttelephones 1 08 within the particular ACD skill/split 
hunt group 106. The ACD skill/split hunt group 106 may 
select an agent telephone 108 if this is the only agent 
available to take a call or on the basis of an agent being 

40 idle the longest if multiple agents are available to take 
a call. As shown in Figure 1, the ACD 102 may have 
multiple route points 103, multiple routing programs 
104, multiple ACD vectors 105, and multiple ACD skill/ 
split hunt groups 106. Each ACD skill/split hunt group 

45 1 06 will usually include multiple agent workstations 1 20. 
[0006] A call control application server 1 1 0 communi- 
cates with the ACD 102 through a computer-telephony 
integration ("CTI") link 109. The call control application 
server 110 comprises a standard computing system, 

50 such as a personal computer ("PC"), and a CTI server 
application that processes calling information for an 
agent via a softphone application 111 at the agent work- 
station 1 20. Each agent typically has a terminal that pro- 
vides a GUI to the softphone application 111 The soft- 

55 phone application 111 emulates the button functions of 
aconventional ACD/PBXfeature phone. The call control 
application server 110 synchronizes the softphone ap- 
plication 111 with the ACD 102 by sending event mes- 



2 



3 



EP 1 035 718 A1 



4 



sages to the softphone application 111 pertaining to the 
agent's telephone 1 08. The call control application serv- 
er 110 services telephony commands from the soft- 
phone application 111 to provide the agent with a soft- 
phone. In atypical configuration, each agent has access 
to an individual copy of the softphone application 111 at 
his or her workstation 108. The softphone application 
111 servicing each agent workstation 108 may be run 
from the call control application server 110, for example, 
in an internet browser-based implementation. The com- 
bination of the agent workstation 120 utilizing a POTS 
such as the telephone 108 and the softphone applica- 
tion 111 provides the agent with the features available 
on more expensive ACD/PBX feature phones. 
[0007] The agent telephones 108 typically receive 
calls directed to either of two numbers. The first number 
is the telephone number for the telephone instrument 
itself, known as the Phone Directory Number ("Phone 
DN"). The second number is a telephone number cor- 
responding to the agent, known as an Agent Directory 
Number ("Agent DN"). The Agent DN follows an individ- 
ual call center agent. Thus, an agent may switch from 
one agent workstation 1 20 to another agent workstation 
120 and still retain the same Agent DN. The Agent DN 
constitutes a personal telephone number for the agent 
and returns a fast busy signal if the agent is not logged 
into the ACD 1 02 or a busy signal when the agent is on 
another call. 

[0008] In a softphone-equipped call center, such as 
the call center shown in Figure 1, a customer call 100 
may reach an individual agent in several different ways. 
The customer call 1 00 may reach the agent through the 
ACD route point 103. This method of calling does not 
necessarily reach a specific agent but instead reaches 
any available agent in the ACD skill/split hunt group 1 06. 
This method provides general calling but is unsuitable 
for reaching a specific agent. If no agent is available in 
the ACD skill/split hunt group 106 when a call arrives, 
the ACD 102 simply queues the call for processing by 
the next available agent. In some call centers, the ACD 
102 may direct a light to flash at the agent workstation 
120 when a call arrives through an Agent DN. A call may 
also reach an agent by being directed through the PSTN 
101 tothe Agent DN ortheagenttelephone's Phone DN. 
[0009] When an ACD agent is available to take anoth- 
er call, the ACD 102 concurrently sends an event mes- 
sage via a CTI middleware product to the agent's work- 
station 1 20 that causes an application in the workstation 
to present customer data about the call to the agent. The 
event message contains user data associated with the 
phone call that is supplied by the ACD or via external 
data sources accessed by the CTI middleware. For ex- 
ample, the event message user data may contain the 
calling party's translated automatic number identifica- 
tion ("ANI") (who is calling) and the dialed number iden- 
tification service ("DNIS") (why they are calling). The 
workstation application interprets the event user data to 
provide a data presentation tothe agent. This data pres- 



entation is known as a "screen pop" as the agent's work- 
station monitor suddenly displays the customer informa- 
tion. The screen pop should arrive slightly ahead of, or 
concurrent with, the arrival of the call at the agent's tel- 
5 ephone 108, which typically includes an audio headset. 
Sometimes the call arrives at an agent's headset before 
the screen pop, compelling the agent to begin with a 
general greeting without knowing to whom he is speak- 
ing. Such errors prevent the agent from quickly assess- 
ing how to treat the call. 

[001 0] A call center may also have one or more robot- 
ic call-handling applications that process all or part of a 
customer call. A robotic call-handling application's re- 
quirements resemble those of a softphone application. 
The primary difference is that the softphone manages 
calls arriving at a specific Phone DN while a robotic call- 
handling application manages calls arriving at a specific 
route point 1 03, also known as a Route Point DN. A ro- 
botic call-handling application may communicate with 
both the route point 103, the ACD skill/split hunt group 
1 06, and the Agent DN and the Phone DN at the agent's 
workstation 120. Some robotic applications may receive 
information from the customer calls 100 and may, in 
some instances, handle a call in a manner much like 
that of a call center agent. For example, a robotic call- 
handling application may utilize an interactive voice re- 
sponse ("IVR") system in the processing of a customer 
call. As robotic technologies grow more sophisticated, 
robotic applications may even begin replacing many, or 
in some instances all call center agents. In many in- 
stances, robotic applications require capabilities be- 
yond those required by human call center agents, such 
as handling many more calls than a human agent. 
[0011] An enterprise may have more than one call 
center, and the call centers may have a variety of con- 
figurations and provide different processing capabilities. 
Enterprises having multiple call centers typically want to 
unify the disparate pieces of their call processing capa- 
bilities in order to provide consistent and balanced call 
processing. Balancing the utilization of geographically 
distributed resources in various call centers against the 
demand for such resources is known as "load balancing. 
" For example, if call center A has the capacity to handle 
100 calls per minute and currently there are no idle 
agents with many calls waiting to be serviced, while call 
center B has the capacity to handle 200 calls per minute 
but has many idle agents, load balancing would balance 
the incoming calls across both call centers to take ad- 
vantage of the idle agents in call center B to provide bet- 
ter service to the customers calling into call center A. 
[0012] Load balancing is especially appropriate in 
customer-facing call centers that handle inbound phone 
calls and whose agents receive calls from an ACD/PBX, 
such as the ACD 102 shown in Figure 1. One type of 
software system that performs load balancing across all 
such call centers at the PSTN network level is conven- 
tionally known as a "Network ACD." Another type of soft- 
ware system that performs load balancing across such 
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call centers at the customer premise equipment ("CPE") 
ACD level is conventionally known as an "ACD with a 
load balancing option," although sometimes such CPE 
ACD implementations are also referred to as a "Network 
ACD." A Network ACD may comprise a collection of 
CPE ACDs as well as an ACD that resides in the tele- 
phone network that feeds a collection of like or disparate 
CPE ACDs. An exemplary CPE ACD is the Lucent 
Definity ACD. Typically, the like kind CPE ACDs will 
have a Load Balancing software feature package, 
sometimes referred to as a "Network ACD" option. A 
conventional Network ACD that operates at the PSTN 
network level is the Geotel Intelligent CallRouter®. For 
example, in an enterprise call environment, load balanc- 
ing may mean that calls entering the enterprise's Net- 
work ACD's queues are distributed across multiple call 
centers in such a manner that the load (call volume) at 
each call center is commensurate with the capability of 
the ACD resources at each call center to service calls 
in a timely manner. 

[001 3] Figure 2 illustrates a conventional load balanc- 
ing scheme provided by a Network ACD operating at the 
PSTN network level. A load balancing system 210 com- 
prises a Network ACD 201 and ACDs 202-206. The 
ACDs 202-206 may be located in one or more call cent- 
ers, and the ACDs 202-206 may be CPE ACDs. Cus- 
tomer calls reach the load balancing system 210 
through the PSTN 101. The ACDs 202-206 provide sta- 
tistical information regarding utilization of their call 
processing capabilities. The Network ACD 201 exam- 
ines the statistical information provided by the ACDs 
202-206 to select an ACD to receive a customer call. 
Thus, the Network ACD distributes calls to the ACDs 
202-206 while the ACDs 202-206 return service statis- 
tics to the Network ACD 201 . The Network ACD 201 se- 
lects an ACD to receive a customer call solely upon met- 
rics related to remaining or non-utilized call handling ca- 
pacity in the ACDs 202-206. 

[0014] The load balancing system 210 may utilize as 
its load balancing metric the current service level 
achieved in each of the ACDs 202-206. Some conven- 
tional load balancing systems utilize even cruder met- 
rics. An example of a service level is the average speed 
to answer ("ASA"), or the average time that a call waits 
in queue before being directed to an agent. One of the 
principles underlying most conventional load balancing 
systems is that a larger ACD service team is more effi- 
cient than several smaller service teams. Accordingly, 
the load balancing system 210 provides the appearance 
of a virtual service team across physically separate lo- 
cations. 

[001 5] ACD manufacturers implement load balancing 
using a variety of schemes. In an enterprise consisting 
of multiple, geographically dispersed call centers, load 
balancing may be accomplished by having a Network 
ACD examine the expected service level to be achieved 
at each call center and then move the call to the "best" 
call center to meet expected service objectives. The 



load balancing system typically assesses the "best" call 
center in less than 500 msec, i.e., a value determined 
by the telephone network providers as a required deter- 
minant of allowing a third party application (the Network 
5 ACD 201 ) to route a call. For calls not routed by the Net- 
work ACD 201 in less than 500 msec, the telephone net- 
work provider will distribute the call on the basis of de- 
fault programming. Moving the call into the ACD of a 
particular call center {e.g., the ACD 206) places further 
processing of the call under the control of the ACD and 
not the Network ACD 201 . The ACD will eventually dis- 
tribute the call to an agent having telephony equipment 
controlled by the ACD. Accordingly, once a customer 
call is moved to a specific ACD ; the limitations of a small 
agent pool re-appear as the cost of moving the call back 
to the Network ACD 201 may be too expensive. Some 
Network ACDs can move a call back up to the telephone 
network and redistribute the call, but such processing is 
expensive and is typically performed on a per call basis. 
[0016] Each ACD 202-206 in the load balancing sys- 
tem 210 provides statistics regarding the actual service 
achieved (e.g., the ASA) to the Network ACD 201 in or- 
der to allow the Network ACD 201 to perform load bal- 
ancing. The Network ACD 201 does not typically know 
which agent received a specific call. Thus, the Network 
ACD 201 does not directly know the actual service pro- 
vided. For that matter, no piece of equipment in the load 
balancing system 210 knows the actual level of service 
provided by the enterprise in processing customer calls. 
[0017] A collection of like-manufacturer CPE ACDs 
may effect call routing via a multi-site ACD load balanc- 
ing software package. However, even a multi-site ACD 
software package eventually moves calls to a queue on 
a CPE ACD for distribution to an agent with the expec- 
tation that the calls residing in that particular queue (or 
queues) will provide the best possible service to the call- 
ing customer. 

[0018] An enterprise may utilize a Centrex system in 
addition to or instead of using CPE ACDs. In a Centrex 
system : the local telephone company provides the en- 
terprise with customer calling telephone services from 
its offices. Even a Centrex system performs load bal- 
ancing as discussed above. While the Network ACD and 
one or more CPE ACDs may be the same piece of 
equipment in a Centrex system, a conventional Centrex 
system nevertheless utilizes a Network ACD software 
package that controls call routing in the manner de- 
scribed above. Thus, even a Centrex system performs 
load balancing for an enterprise on the basis of balanc- 
ing a load rather than on meeting the enterprise's serv- 
ice objectives. An exemplary Centrex Network ACD 
package is Lucent's TOPMS which distributes calls 
base on percent capacity to the underlying CPE ACDs. 
[0019] Figure 3 is a flowchart depicting call routing in 
a conventional Network ACD load balancing system. A 
Network ACD receives a call (step 301) The Network 
ACD uses the ANI and DNIS to determine the service 
to be provided via a database lookup against a database 



15 



20 



25 



30 



35 



40 



45 



50 



4 



7 



EP 1 035 718 A1 



8 



containing routing information (step 303). The Network 
ACD examines statistics for all of the ACDs operating 
under the load balancing scheme (step 305) that can 
service this call. For example, if the incoming call is to 
customer service, there may be 15 ACDs to which calls 
can be directed; but only 10 handle customer service 
requests. Based upon the ACD statistics, the Network 
ACD selects an ACD for the call based on the ACD hav- 
ing the most appropriate statistics (step 307). As previ- 
ously discussed, the most appropriate statistics will typ- 
ically be the ACD having the best service level. The Net- 
work ACD then transfers the call to the selected ACD 
(step 309). 

[0020] The ACD receives the call sent to it from the 
Network ACD (step 311). The ACD analyzes the call to 
select an appropriate split/skill hunt group (step 313). 
The ACD then selects an available agent in the split/skill 
hunt group based upon whether an agent is presently 
available or is the longest idle agent (step 315). If no 
agent is presently available (step 31 9), then the ACD 
may send the call to another split/hunt group (step 321 ) 
before routing the call back through the agent selection 
process (step 315). As the result of considering other 
agent distribution options (step 321), the ACD may de- 
termine that other agents can be considered in order to 
meet service objectives. For example, calls for Platinum 
customers are not being answered by Platinum custom- 
er agents to meet an ASA service objective of 10 sec- 
onds, therefore after waiting 2 seconds with no agent 
from the pool of Platinum customer agents available, 
both Platinum customer agents and Gold customer 
agents will be considered acceptable to answer Plati- 
num customer calls. If an agent is available (step 319), 
then the ACD transfers the call to the agent while simul- 
taneously sending a CTI event to external server based 
"screen pop" software that a call is about to be delivered 
to a specific agent's phone. This external software pop- 
ulates data associated with the call and then executes 
a "screen pop" instruction (step 323) to an application 
at the agent's desktop. The desktop application receives 
the data associated with this call along with CTI call 
event notification and processes the data to provide a 
"screen pop. " The agent then processes the call accord- 
ing to the enterprise business directives. 
[0021] As described above, the conventional proce- 
dure for routing customer calls in an enterprise environ- 
ment has been based upon balancing the load among 
the various components that comprise the enterprise's 
call-handling capability, e.g., the ACDs. While the con- 
ventional process may be adequate for balancing the 
load among the enterprise's various call-handling com- 
ponents, the conventional procedure does little in the 
way of accomplishing an enterprise's business objec- 
tives with regard to its customers and to its resources, 
such as its call center agents. In addition . the conven- 
tional procedure does not address customer communi- 
cations arriving from communication media other than 
telephones. 



SUMMARY OF THE INVENTION 

[0022] The invention provides a method and system 
for processing an enterprise's incoming customer com- 

5 munications on the basis of the enterprise's business 
objectives. Embodiments of the invention deliver serv- 
ices to an enterprise's customers across all lines of the 
enterprise's business and treats customers in a consist- 
ent manner independent of their entry point into the en- 

10 terprise's business communication facilities. Embodi- 
ments of the invention tie together physically separate 
business communication centers, including "back of- 
fice" sites not normally associated with processing cus- 
tomer communications. 

15 [0023] Embodiments of the invention provide an en- 
terprise service balancer that distributes work based up- 
on enterprise service objectives, enterprise resources 
and immediate resource availability. The enterprise 
service balancer provides an instantaneous best possi- 

20 ble service for a customer communication {e.g., a call) 
by matching the customer communication with the most 
appropriate resource in the enterprise, as a whole, in 
accordance with the enterprise's definition of best serv- 
ice. Unless a customer communication is directed to a 

25 specific agent, embodiments of the enterprise service 
balancer refrain from moving a customer communica- 
tion until a resource(s) has identified itself as available. 
The enterprise service balancer may provide a virtual 
call center that unites the enterprise's various telephony 

30 elements, such as physically separate call centers, to 
provide a unified call-handling capacity for the enter- 
prise. Agents, or agent applications, may make them- 
selves available for taking a higher priority work, such 
as a call over the work currently performed, according 

35 to an embodiment of the invention. Therefore, identify- 
ing oneself as "available" may be "available for specific 
types of work which can interrupt current work " For ex- 
ample, an agent may be working on a billing adjustment 
work type but will make himself available for taking a 

40 Platinum Customer phone call billing related work type. 
[0024] Embodiments of the enterprise service balanc- 
er processes calls on the basis of specific customer and 
agent characteristics. The enterprise service balancer 
further accommodates an enterprise's various defini- 

45 tions of the appropriate resource by referencing a re- 
source's skills set. When the enterprise receives a call 
from a customer that requires a certain skills set, an en- 
terprise service balancer processing calls according to 
the definition of "appropriate resource" looks for an 

so available agent in the enterprise who has that skills set. 
[0025] Embodiments of the enterprise service balanc- 
er operate in conjunction with enterprise resources as 
diverse as call center agents, back office agents, and 
robotic call processing applications. The back office 

55 agents, such as technical staff members, represent per- 
sons who do not typically handle inbound customer 
communications. The robotic call processing applica- 
tions may operate in conjunction with an interactive 
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voice response ("IVR") system. Embodiments of the en- 
terprise service balancer may receive and process cus- 
tomer communications such as telephony calls, e-mail, 
video kiosk, and the Internet. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0026] An embodiment of the invention will be de- 
scribed below relative to the following figures. Note that 
similar elements and steps in the figures have the same 
reference number. 

[0027] Figure 1 illustrates a conventional softphone- 
configured call center. 

[0028] Figure 2 illustrates a conventional load balanc- 
ing scheme provided by a Network ACD operating at the 
public switched telephone network ("PSTN") level. 
[0029] Figure 3 is a flowchart depicting call routing in 
a conventional Network ACD load balancing system. 
[0030] Figure 4 illustrates an enterprise service bal- 
ancing system 410, according to an embodiment of the 
invention. 

[0031] Figure 5 illustrates a call center 510 that has 
been configured to operate in conjunction with an enter- 
prise service balancing application, according to an em- 
bodiment of the invention. 

[0032] Figure 6 illustrates a call center 640 that pro- 
vides enterprise service balancing without requiring uti- 
lization of an ACD. 

[0033] Figure 7 illustrates exemplary ESB selection 
criteria 701 that provide data for enabling an embodi- 
ment of the enterprise service balancer 401 to deter- 
mine the precise enterprise resource to receive a call. 
[0034] Figure 8 illustrates a representative ESB agent 
table 800 that contains the type of data that an enter- 
prise may wish to collect regarding its call center agents 
and then reference when selecting an appropriate re- 
source for a call. 

[0035] Figure 9 provides further details regarding 
workpackets transferred to enterprise resources. 
[0036] Figure 1 0 illustrates the linking of workpackets 
in a call parking facility utilized by the enterprise service 
balancer while attempting to find an appropriate re- 
source to process the call represented by the workpack- 
et, according to an embodiment of the invention. 
[0037] Figure 1 1 illustrates an exemplary agent work- 
station 1110 for processing workpackets, according to 
an embodiment of the invention. 

[0038] Figure 1 2 illustrates additional information that 
may be retrieved in an exemplary workpacket 1200 
processed by an enterprise resource. 
[0039] Figures 13A and 13B comprise a flowchart 
1 300 illustrating the processing of a call in an enterprise 
service balancing system 410 utilizing an enterprise 
service balancer 401, according to an embodiment of 
the invention. 

[0040] Figure 14 illustrates an exemplary enterprise 
service balancing system 1410 that processes custom- 
er communications arriving from a variety of media, ac- 



cording to an embodiment of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

5 [0041] Embodiments of the invention provide a meth- 
od and system for processing an enterprise's customer 
communications on the basis of the enterprise's busi- 
ness objectives, known as enterprise service balancing, 
rather than solely upon aggregate statistical measures 
10 pertaining to the enterprise's automatic call distributors 
("ACDs") or private branch exchanges ("PBXs"). Enter- 
prise service balancing ties together physically separate 
business communication centers, including "back of- 
fice" sites not normally associated with processing cus- 
15 tomer calls. BackOffice sites may include employees not 
normally associated with call center operations : such as 
the enterprise's technical staff, enterprise branch loca- 
tions, enterprise partners and affiliates, and even other 
enterprise customers. Enterprise service balancing de- 
20 livers services to customers across all lines of an enter- 
prise's business and treats customers in a consistent 
manner independent of their entry point into the enter- 
prise's business communication facilities. 
[0042] In contrast to enterprise service balancing, 
25 conventional Network ACDs focus upon agent capacity 
statistics and/or service ach ieved statistics for individual 
customer premise equipment ("CPE") ACDs and do not 
allow an enterprise to process calls based upon specific 
customer and agent characteristics. For example, Net- 
so work ACDs cannot process calls on the basis of an in- 
dividual agent's skills. A Network ACD's limitations arise 
both from moving calls to queues not controlled by the 
Network ACD, such as a queue controlled by a CPE 
ACD, and from having no real control over the service 
35 provided by the CPE ACD once it receives a call. 

[0043] Enterprise service balancing enables the 
processing of customer calls according to business ob- 
jectives by the appropriate resource, such as an agent, 
regardless of the resource's location. Enterprise service 
40 balancing accommodates an enterprise's various defi- 
nitions of the appropriate resource by referencing a re- 
source's skills set, e.g., process loans and interact with 
platinum-level customers An enterprise service balanc- 
ing system processing calls under this definition of "ap- 
45 propriate resource" looks for an agent who handles plat- 
inum-level customers and loan inquiries when the en- 
terprise receives a call from a platinum-level customer 
regarding a loan. In other circumstances, the appropri- 
ate resource may simply be a specific agent, e.g., a cus- 
50 tomer call to the agent who just completed processing 
his loan regarding a specific issue associated with the 
loan. 

[0044] Embodiments of the enterprise service balanc- 
ing system provide a virtual call center comprised of the 
55 enterprise's various telephony elements, such as phys- 
ically separate call centers, by linking the enterprise's 
telephony elements together in such a manner so as to 
provide a unified call-handling capacity for the enter- 
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prise. A virtual call center escapes the rigid design of 
conventional call centers by providing a more amor- 
phous and flexible design than previously possible. Em- 
bodiments of the invention provide an enterprise service 
balancer that distributes work in a deterministic manner 
based upon resource skills and immediate availability. 
The enterprise service balancer provides the "instanta- 
neous" best possible service for a customer request (a 
g., a call) by matching the request with the most appro- 
priate resource in the enterprise for processing the cus- 
tomer request in accordance with the enterprise's ap- 
propriate "best service" definition. Embodiments of the 
enterprise service balancer define "instantaneous" as 
the moment that a resource is available to work on the 
next work item. 

[0045] Embodiments of the enterprise service balanc- 
er refrain from moving a call until after identifying an 
available resource in the enterprise as a whole who can 
best handle the call. Furthermore, the resource may not 
necessarily be a call center agent. The resource may 
be a back office agent such as a technical staff member, 
who normally does not handle inbound phone calls. The 
resource may further comprise a robotic call processing 
system having a skills set capable of processing the cus- 
tomer's call. The robotic call processing system may op- 
erate in conjunction with an interactive voice response 
("IVR") system. 

[0046] In the preferred embodiment, the enterprise 
service balancer provides service on a call-by-call basis 
(or customer call-by-customer call basis) based upon a 
resource (e.g., an agent) that has just come available 
rather than selecting a resource by moving calls to a 
queue associated with only a portion of the enterprise's 
call-handling capabilities (e.g., a queue associated with 
a CPE ACD). When a resource comes available to take 
a next work item (e.g., a call), the enterprise service bal- 
ancer selects the best customer call from all calls avail- 
able in the enterprise that meets this resource's skills 
and that meets enterprise service objectives. Even in 
the event that a call is meant for a specific resource, 
such as a specific agent, the enterprise service balancer 
may have the agent take another call instead because 
the other call better meets the overall enterprise service 
objectives. 

[0047] For a call requiring a specific set of skills, the 
enterprise service balancer sends the call to the first re- 
source (e.g., an agent) having the necessary skills set 
who comes available and for whom the call is the best 
work for the resource to perform at that moment. The 
call is sent to this resource when the resource requests 
the call from the enterprise service balancer by provid- 
ing its telephone set address (e.g., a Direct Inward Di- 
aling ("DID") number) to the enterprise service balancer. 
The enterprise service balancer holds the call at its point 
of arrival into the enterprise and waits (e.g., parks the 
call) until moving it to a specific resource by simply trans- 
ferring the call to the destination resource's telephone 
set address using conventional PBX technology. Con- 



ventional PBXtechnology can be via a computer-teleph- 
ony integration ("CTI"), via an external device (e.g., an 
IVR), or other available means. Thus, the enterprise 
service balancer may move a call directly to a selected 
5 resource and bypass the inflexible processing normally 
performed by a CPE ACD. 

[0048] Figure 4 illustrates an enterprise service bal- 
ancing system 410, according to an embodiment of the 
invention. The enterprise service balancing system 410 

10 comprises an enterprise service balancer 401, a data- 
base 402, a call center 403, employee resources 404, 
and another call center 405. The call centers 403, 405 
and the employee resources 404 and may each respec- 
tively include workstations 406-409. An exemplary en- 
75 terprise service balancing system, according to the in- 
vention, may comprise additional call centers and em- 
ployee resources beyond those depicted in Figure 4. 
[0049] The call centers 403, 405 may comprise call 
centers utilizing ACD/PBXs, call centers equipped with- 

20 out ACDs, and any facility that receives incoming and/ 
or places outgoing calls under the direction of an agent, 
whether human or robotic. The principal requirement for 
distribution of calls is that an agent have a unique ad- 
dress representing the agent's telephony device where 

25 when an external party dials this address, the agent's 
telephony device can be connected either over the Pub- 
lic Switched Telephone Network ("PSTN") or a private 
network. Of course, the agent's telephony device may 
comprise a standard telephone set, a head set device, 

30 and even a telephony card installed in a computing de- 
vice, such as a personal computer ("PC"). The employ- 
ee resources 404 represent those portions of the enter- 
prise that are not normally represented in call centers, 
e.g., back office employees. For example, various spe- 

35 cialized activities, such as the enterprise's technical 
staff, may be represented by the employee resources 
404. These employees may not have addresses directly 
accessible from the PSTN using a simple phone 
number, however, in this case they can be accessed by 

40 equipment such as a PBX auto-attendant for which the 
supplied address to the enterprise service balancer 
would be the auto-attendant number on the PBX fol- 
lowed by the specific employee extension (e.g., 
"425-445-4545 ext. 2379"). This is an example of a mix 

45 of PSTN and private network addressing. The call cent- 
ers 403, 405 may comprise facilities whose services are 
provided to the enterprise under a contract (e.g., via a 
Centrex service) where the agents would all be acces- 
sible via addresses accessible via the PSTN 

50 [0050] The enterprise service balancer 401 receives 
calls from customers via the PSTN 101 , analyzes each 
call to determine the best possible resource within the 
enterprise service balancing system 410 to receive the 
call, then makes the call retrievable by the resource 

55 once it becomes available. Unlike a Network ACD, the 
enterprise service balancer 401 may not necessarily re- 
ceive calls directly from the PSTN 1 01 . For example, the 
enterprise service balancer 401 may actually wrap 
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around each of the elements within the enterprise serv- 
ice balancing system 41 0 : such as the call center 403. 
Thus, the enterprise service balancer 401 may be inte- 
grated into conventional ACD/PBX equipment. In such 
an embodiment, the call center 403 directly receives a 
customer call from the PSTN 101, parks the call, and 
then requests the enterprise service balancer 401 to se- 
lect an appropriate resource to process the call in ac- 
cordance with enterprise-wide objectives. 
[0051] The enterprise service balancer 401 achieves 
resource-specificity in meeting service objectives 
across the entire enterprise service balancing system 
410 by utilizing an enterprise workflow system to create 
a work item for each call as it arrives at a call center, 
according to a preferred embodiment of the invention. 
A workflow system both captures and moves informa- 
tion regarding a business transaction (e.g., a customer 
call) through a work process, ensuring that each enter- 
prise resource can access the information items re- 
quired to perform its portion of a transaction. Workflow 
systems may also provide a context for performing work, 
allowing resources to concentrate on the work at hand, 
rather than on the process itself. Workflow software, 
such as that utilized in the enterprise service balancing 
system 41 0, improves the efficiency of both mission-crit- 
ical and ad-hoc business processes. Such improve- 
ments should reduce costs, enhance quality, provide 
faster turnaround, and improve customer satisfaction. A 
workflow system is not limited to conventional workflow 
systems, such as primarily developed for document 
centric work. A workflow system can be any of a myriad 
system implementations that allows agents to be asso- 
ciated with the processing of work items in a proscribed 
manner. A proscribed manner may be a process de- 
scription of a set of process steps for which human 
agents are associated with some steps and for which 
robotic agents are associated with some other steps, 
where at each step agents may interact with the work 
item 

[0052] The enterprise service balancer 401 process- 
es calls as work items known as "workpackets." A work- 
packet is a container for data elements that represents 
a transaction in progress. For example, in a customer 
service process, a workpacket may contain information 
related to a customer service transaction, such as a bill- 
ing adjustment. The workpacket for this transaction may 
include data such as the identification of the customer 
associated with this transaction, past history of the busi- 
ness interactions with this customer, a classification of 
this customer based on the relationship with the custom- 
er (e.g., Platinum Status), business rules on how agents 
should handle this transaction, pointers to documents 
relative to this transaction (e.g., a pointer to a previously 
received letter, a pointer to the customer's last billing 
statement), and if the transaction is currently active, 
then the workpacket may contain a pointer to the media 
over which the current transaction is occurring (e.g., a 
phone call). A workpacket may represent a transaction 



in progress but not currently being worked on by some- 
one (e.g., waiting for a supervisor signature), or a work- 
packet may be opened by an agent for processing, or a 
workpacket may have just been created based on a cus- 
5 tomer interaction for the customer service example. A 
workpacket is an example of a New Work Item for which 
an agent is to perform work. According to a preferred 
embodiment, for a customer interacting over a tele- 
phone, then each workpacket contains a pointer to a re- 
spective call being held somewhere within the enter- 
prise service balancing system 410, such as in the call 
center 403. For example, a call may be parked at an 
ACD routing control point in an ACD within the call cent- 
er 403. Of course, other calls may be parked at other 
ACD routing control points in other ACDs within other 
call centers or other similar equipment, with all of these 
call centers linked together by the enterprise service bal- 
ancer 401 . The enterprise service balancer 401 pro- 
vides forthe creation and manipulation of the items com- 
prising the workpackets, the creation and management 
of agent attributes, the definition and management of 
service levels, and the distribution of the workpackets. 
[0053] The enterprise service balancer 401 adds 
each new workpacket for a newly arrived call to a work- 
list of workpackets. The worklist essentially amounts to 
a workpacket parking lot, comprising workpackets wait- 
ing for processing by an enterprise resource, such as 
an agent. The enterprise service balancer 401 provides 
the workpacket with attributes about the customer call 
from other applications, such as database queries or 
IVR interactions. IVR inquiries may be performed by a 
network IVR or a customer premise equipment ("CPE") 
IVR associated with a CPE ACD. The enterprise service 
balancer 401 , or other pertinent equipment, still queues 
the call either at the IVR or the ACD routing control point 
until it is directed to a selected resource. The enterprise 
service balancer 401 ultimately determines that the 
workpacket is ready for distribution to the specific re- 
source that can process the workpacket. In some em- 
bodiments of the invention, elements of the workpackets 
may also represent data from other types of media with 
which the enterprise may interact, such as processing 
live video connections with customers, e-mail messag- 
es, and internet communications. Accordingly, the in- 
vention is not limited to processing only incoming calls 
through conventional telephony devices. 
[0054] The enterprise service balancer 401 may uti- 
lize the database 402 in directing each incoming call to 
the appropriate resource within the enterprise service 
balancing system 41 0, whether to an agent in a call cent- 
er or to an appropriate back office employee resource. 
The enterprise service balancer 401 analyzes each in- 
coming call to determine its pertinent characteristics. 
During its analysis, the enterprise service balancer 401 
may retrieve pertinent data stored in the database 402. 
In addition, the enterprise service balancer 401 may 
query the incoming call to determine additional charac- 
teristics. The querying of the incoming call may include 
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intrinsic characteristics determined from the call itself 
(such as those provided by Caller ID and by analysis of 
the number called by the caller) and may also include 
characteristics provided by interaction with the caller 
(such as through a numeric telephone keypad or 
through an IVR). The enterprise service balancer 401 
may additionally examine information regarding re- 
sources, such as agents, within the call centers 403, 405 
and characteristics regarding employees within the em- 
ployee resources 404. 

[0055] Once the enterprise service balancer 401 has 
determined an appropriate resource to process the call, 
then the enterprise service balancer 401 may transfer 
the call to the selected resource. According to a pre- 
ferred embodiment, the enterprise service balancer 401 
sends the workpacket, or other indicia of the call's con- 
tents, to the selected resource. In the preferred embod- 
iment of the invention, the enterprise service balancer 
opens the workpacket to obtain the parking location of 
the call (the workpacket pointer to the media, in this case 
a parked phone call) and then delivers the call to the 
selected resource's telephony device using that re- 
source's network address. In other embodiments, the 
selected resource may review the workpacket before 
speaking with the caller. The selected resource may 
choose not to process the call and send an indication to 
the enterprise service balancer 401 that another re- 
source should be found to process the call. In still other 
embodiments of the invention, the enterprise service 
balancer 401 transfers the workpacket to the resource 
along with the transferred call. In some embodiments, 
the enterprise service balancer 401 may even operate 
in a configurable dual mode, e.g., allowing call refusal 
during low periods of incoming call traffic but disabling 
call refusal during peak call traffic periods. 
[0056] In delivering the media (e.g., a call) to an 
agent, the preferred embodiment of the enterprise serv- 
ice balancer 401 has a work pusher distributed on each 
resource's workstation. For example, the call center 403 
includes the workstations 406, at least some of which 
have a work pusher 41 0. Similarly, the workstations 407 
on the employee resources 404 may also include a work 
pusher 411 and the call center's 405 workstations 409 
may also include a work pusher 412. The work pusher 
410 selects a workpacket based on meeting objectives 
established dynamically by the enterprise service bal- 
ancer 401, pushes the workpacket to its workstation 
406, opens the workpacket, and then requests the com- 
ponent parking the particular call to send the call to the 
workstation's associated telephony device. In another 
embodiment, the enterprise service balancer 401 itself 
contains a work pusher that identifies the work for one 
or more resources. In both embodiments, the work 
pusher pushes the workpacket to a workstation, and 
when the workpacket is opened, the pointer to the call 
directs the call from the park location to the agent's te- 
lephony device. The workstation knows {e.g., the work- 
station 406) its telephony device address and provides 



this address to the enterprise service balancer 401 . The 
workstation 406 may either provide the address to the 
work pusher when the work pusher 410 is distributed to 
the workstation 406 or the address may be stored in the 

5 database 402 when enterprise service balancer 401 
contains the work pusher. The workpacket pushed to the 
workstation causes call delivery to the associated te- 
lephony device. In comparison, in a conventional Net- 
work ACD delivery of the phone call to the telephony 

10 device causes the data associated with a call to be 
opened. As should be readily apparent to an ordinary 
artisan, the enterprise service balancer 401 may be dis- 
tributed. For example, the enterprise service balancer 
401 may be distributed across each of several call cent- 
's ers, such as the call centers 403 and 405, and/or other 
centers containing employee resources, such as the 
employee resources 404. An apparatus that transfers 
calls may also reside within the work pusher 41 0 rather 
than in the enterprise service balancer 401, according 

20 to an embodiment of the invention. 

[0057] The enterprise service balancer 401 process- 
es calls on the basis of an enterprise-wide customer at- 
tribute description that may be stored in the database 
402. The customer attribute description provides a con- 

25 figurable template of the characteristics that should be 
collected regarding the call to determine its best dispo- 
sition within the enterprise service balancing system 
410. The customer attribute description includes those 
attributes helpful in selecting a call center agent as well 

30 as those attributes helpful in selecting an employee re- 
source. Characteristics within the customer attribute de- 
scription may be ranked in order of importance, and 
combinations of characteristics may also be ranked in 
order of importance. For example, a call's requirement 

35 for an agent fluent in French at a high level of proficiency 
may be classified as more important than the agent's 
loan processing skills. By capturing the characteristics 
and relationships among the characteristics of impor- 
tance to the enterprise, the enterprise service balancer 

40 401 may process each received call in a manner that 
best achieves the enterprise's overall goals. 
[0058] The enterprise service balancer 401 may also 
be configured to utilize call attributes, such as the cost 
of moving a call, in determining the best resource to 

45 meet the enterprise's objectives. Considering transpor- 
tation costs when making routing decisions can reduce 
operating costs. Let's assume that there are two agents 
of equal skill, but one is on the East Coast and the other 
is on the West Coast Furthermore, let's assume that it 

50 is less expensive to move an East Coast call to an East 
Coast agent. A call arrives at the enterprise service bal- 
ancing system 410 on the East Coast. To achieve the 
desired service level, the call will be moved to the East 
Coast agent if the workpacket attributes used by the en- 

55 terprise service balancer 401 favor using East Coast 
agents for East Coast Calls even though the West Coast 
agent has equal skill to make the call. In other words, 
unless other call attributes outweigh the cost of trans- 
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ferring the call, the call will remain on the East Coast. 
[0059] Figure 5 illustrates a call center 510 that has 
been configured to operate in conjunction with an enter- 
prise service balancing application, according to an em- 
bodiment of the invention. Because the enterprise serv- 
ice balancing system distributes the call and not an 
ACD, a call-receiving resource does not need to be an 
ACD agent but can be a back-office agent who has tel- 
ephone connectivity to a PBX that is interconnected with 
the ACD. This is another distinct advantage of an enter- 
prise service balancing system over a conventional Net- 
work ACD. The call center 510 may accommodate an 
embodiment of an enterprise service balancing system 
without requiring either a hardware modification of the 
ACD 102 or the addition of any new equipment inside 
the ACD 102. 

[0060] A client call arrives at the ACD 102 and is re- 
ceived in the route point 1 03. The route point 1 03 directs 
the call as instructed by the routing program 104. The 
routing program 104 directs the call to a first enterprise 
service balancing ("ESB") route point 502. A routing in- 
struction 503 associated with the first ESB route point 
502 transfers the call after a configurable time period to 
a second ESB route point 504. The second ESB route 
point 504 contains a routing instruction 505 that in turn 
redirects the call, after a configurable time period, back 
to the first ESB route point 502. The call continues to be 
routed back and forth between the two ESB route points 
until the call is otherwise disposed. Exemplary methods 
and systems for parking calls using route points in an 
ACD/PBX are disclosed in U.S. Patent Application No. 
09/060,038, "Multiple Call Handling in a Call Center," 
filed on April 13, 1998, assigned to the Mosaix Corpo- 
ration, and which is incorporated herein by reference. 
[0061] An ESB application 506 receives notification of 
the call's arrival through the CTI link 109. The ESB ap- 
plication 506 may have even directed the transfer of the 
call into the first ESB route point 502 in some embodi- 
ments of the invention. In any event, the ESB application 
506 makes a relevant notation regarding the call in a call 
database 507. The ESB application 506 continues to re- 
ceive updates regarding the location of the call and 
stores such information in the call database 507. 
[0062] The ESB application 506 on call arrival creates 
a workpacket for the call and inserts into the workpacket 
pertinent information relative to the call, such as the call 
location, the automatic number identification ("AM") 
(who is calling), the dialed number identification service 
("DNIS") (why they are calling), customer entered digits, 
IVR interaction data, business rules for handling the 
transaction, pointers to stored information such as doc- 
uments, and past transaction histories. 
[0063] The ESB application 506 analyzes the call and 
consults an enterprise database 508 to determine a 
proper resource 501 to receive the call presently parked 
in one of the first and second ESB route points 502, 504. 
The ESB application 506 tags the call with this set of 
resources. The tag may be a list of resources in an ESB 



having a centralized work pusher or may be simply the 
required resource attributes in an ESB with distributed 
work pushers. Once the ESB application 506 has se- 
lected a set of resources 1 20 for the call, or has simply 
5 associated the resource attributes required to service 
the call, then the ESB application 506 waits for one of 
the resources 120 to become available. When one of 
the resources 120 becomes (or is) available, then the 
ESB application 506 forwards the workpacket to a spe- 
cific one of the resources 501 . As previously described, 
the workpacket contains a pointer to the call in the call 
database 507. The resource 501 may review the work- 
packet and decide whether to accept the workpacket for 
processing or return it to the ESB application 506, ac- 
cording to some embodiments of the invention. The re- 
source 501 is typically associated with an agent work- 
station 120 having a capability for receiving the work- 
packet. The resource 501 may be any capability acces- 
sible by the enterprise that can satisfy the needs of the 
specific call being processed by the enterprise. For ex- 
ample, the resource 501 may be an ordinary telephone 
used by the engineer who designed a particular compo- 
nent of an enterprise product if this particular engineer 
is the best enterprise resource for processing a specific 
call received by the enterprise. 

[0064] If the resource 501 elects to process the work- 
packet, or is required to process the workpacket, the re- 
source 501 may review the workpacket's contents be- 
fore connecting with the call. Once the resource 501 de- 
cides to connect with the call, then the resource 501 re- 
quests the call by sending its telephony device address 
to the enterprise service balancer component that has 
parked the call, (e.g., controlling the call at either the 
first ESB route point 502 or the second ESB route point 
504). The ESB parking component sends a query using 
the workpacket call pointer to the call database 507 to 
determine whether the call is presently located in the 
first ESB route point 502 or the second ESB route point 
504. Using the telephony address provided by the re- 
source 501 , the parking component then formulates an 
appropriate call transfer instruction, using the CTI link 
109 or other first party call control means such as com- 
municating with an IVR, to move the call to the destina- 
tion telephone 108. Alternatively, the ESB application 
506 may formulate a similar transfer instruction for the 
call concurrent with the transfer of the workpacket to the 
resource 501. Of course, other call parking schemes 
may used other than utilizing two route points that have 
been used herein for illustration purposes. For example, 
a call may simply be parked at an IVR port. 
[0065] The ESB application 506 may straddle multiple 
ACDs 102 and may also operate in conjunction with 
non-ACD/PBX equipment, such as the employee re- 
sources 404 shown in Figure 4. Accordingly, embodi- 
ments of the enterprise service balancing system 410 
may be applied to conventional call center installations 
without requiring costly physical modifications. For ex- 
ample, the first ESB route point 502 and the second ESB 
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route point 504 may be added to the ACD 1 02 by simple 
adjustment of the ACD's existing functionality. Exempla- 
ry methods of creating such route points in an ACD/PBX 
are disclosed in U.S. Patent Application No. 09/060,038, 
which has been previously incorporated herein by ref- 
erence. 

[0066] The ESB application 506 in directing a call to 
be transferred from the first or second ESB route points 
502, 504 may even direct the transfer of the call into 
another call center orto other equipment, such as equip- 
ment associated with the employee resources 404 ; ac- 
cording to an embodiment of the invention. Such an em- 
bodiment of the invention would require that the ACD 
1 02 either have a PBX or a phone switch capable of un- 
dertaking such operations. As previously discussed, an 
auto-attendant PBX function may be used to send a call 
to a back-office resource. 

[0067] In the call center 510, the ACD skill/split hunt 
group 1 06 performs little if any processing. However, the 
ACD's routing programs may be configured to utilize the 
ACD skill/split hunt group 106 upon notification that the 
ESB application 506 has ceased processing calls. This 
condition might arise due to error or programmed main- 
tenance. 

[0068] The enterprise service balancing system 410, 
unlike conventional Network ACDs does not typically 
move a call to a resource until the resource is available 
to receive the call. The enterprise service balancer in- 
curs no extra cost to move calls, no expensive ACD 
communications circuits or software to offer calls at mul- 
tiple call centers, no extra cost to move calls a second 
time, and service control is extended to call center 
agents and back-office agents (non-call center agents). 
The enterprise service balancer 401 also extends serv- 
ice to a much larger pool of agents such as may be re- 
quired to meet peak service requests. The enterprise 
service balancer 401 provides greater effectiveness by 
eliminating the need to pass through an ACD's conven- 
tional processing in order to reach the person who will 
process the call. As discussed, the enterprise service 
balancer 401 does not queue a call on a remote ACD 
based on a statistical indication that the call might be 
serviced within an acceptable time period. The enter- 
prise service balancer 401 instead determines service 
with an enterprise wide view at the instant a resource 
becomes available to take a new call. 
[0069] Figure 6 illustrates a call center 640 that pro- 
vides enterprise service balancing without requiring uti- 
lization of an ACD, according to an embodiment of the 
invention. As previously discussed, the enterprise serv- 
ice balancing system 410 does not require that the en- 
terprise utilize an ACD. The enterprise service balanc- 
ing system only requires a telephony switching system 
that may provide third party and at least first party call 
control, such as may be provided by a PBX ; IVR, or a 
simple PC-based switching system. A simple PC-based 
switching system could be a set of hardware cards that 
are part of the workstation that is executing the ESB ap- 



plication. In first party call control, call recipients directly 
control calls through telephony equipment attached to 
their telephone. For example, an IVR represents an ex- 
ample of first party call control wherein the call to be 

s transferred is at an IVR port on the ACD/PBX. The cus- 
tomer requests to speak with an agent, and typically the 
IVR port handling the call performs a blind transfer of 
the customer to an ACD queue. Transfer of the call on 
the IVR port could also be requested by an external ap- 

10 plication; that is the external application makes a trans- 
fer request over a data network to the specific IVR. In 
this case, the IVR port "owns" the call and performs a 
first party call control transfer, just as it had for the cus- 
tomer request to speak with an agent. In some imple- 

15 mentations, the IVR may be standalone and may not be 
connected to an ACD/PBX. In third party call control, call 
recipients, or others, control calls through a connection 
with an ACD/PBX and take control of a call independ- 
ently of the device that currently has control of the call. 

20 An example of third party call control is a CTI link that 
provides control of any call on any phone device to an 
external application. For example, a call is at an exten- 
sion 43400 and a customer is communicating with an 
agent. With third party call control, an external applica- 

25 tion takes this call away from the telephony device 
43400 and performs a supervised transfer of the call to 
a different agent without using the telephony device 
43400 for performing this action. Both third party and 
first party call control allow the enterprise service bal- 

30 ancing system 41 0 to park a call and then distribute the 
call to an enterprise resource, e.g., an agent. Of course, 
as discussed with respect to Figure 5, since ACDs rep- 
resent the predominate telephony switch in convention- 
al call centers ; embodiments of the enterprise service 

35 balancing system will work with any ACD or other 
switching system that provides third party and at least 
first party call control. 

[0070] The call center 640 having three geographic 
sites 630, 632, 634 does not require an ACD and instead 

40 merely requires the use of phone switches 610, 612, 614 
and IVR ports with first party call control 601 , 603 that 
can be controlled by Work Pushers 618, 619. An ordi- 
narily skilled artisan will also note that no CTI link is re- 
quired. The call center 640 may contain more than the 

45 two IVR ports shown in Figure 6. The phone switches 
610, 612, 614 include the equipment necessary to pro- 
vide standard telephony functions, such as a dial tone, 
the ability to make a call, the ability to receive a call, and 
the ability to transfer a call. In addition the phone switch- 

50 es 61 0, 61 2 have the IVR ports with first party call control 
601 , 603 that are accessible to the Work Pushers 618, 
619. Such functionality is typically provided by an IVR 
via IVR software application interfaces. The call center 
640 may be linked with other similar call centers within 

55 the enterprise and may also be linked with other enter- 
prise-operated call centers that utilize an ACD/PBX, 
such as the call center 510 shown in Figure 5. For ex- 
ample, the ESB application 506 may communicate rel- 
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evant information to the call center 640. As previously 
discussed, the enterprise service balancing system 410 
may wrap around the various elements comprising an 
enterprise's existing call-processing capabilities. For 
example, enterprise service balancing capabilities may 
be added to an enterprise's existing ACDs, PBXs or 
IVRs, as well as to newly designed call centers, so as 
to create a call-handling superstructure over the enter- 
prise's communications facilities. The call center 640 il- 
lustrates a distributed call center designed to interface 
with an enterprise service balancing system 620 and the 
work pushers 618, 619, in this instance interfacing with 
equipment and resources in the distributed call center 
sites 630, 632 : 634. 

[0071] The distributed call center 640 further compris- 
es agent workstations 605 : 606, each at a different phys- 
ical location 632, 634 respectively. The call center 640 
may comprise more agent workstations than shown in 
Figure 6. The agent workstations 605, 606 may be con- 
figured for call center type call processing and respec- 
tively include the Work Pushers 618, 619 and tele- 
phones 607, 608 The call center 640 further includes an 
ESB workstation 620. The ESB workstation 620 in- 
cludes an ESB application 611 . The telephone switches 
- the IVRs 610, 612 -- provide a mechanism for parking 
calls while waiting for selected enterprise resources to 
become available. This design has the desired result of 
parking the call at the point of entry to the call center 
640 and not moving a call until the proper resource has 
been identified to receive the call. 
[0072] The call center 640 further includes a staff da- 
tabase 604 that contains data related to agent and em- 
ployee resources throughout the enterprise and in- 
cludes the resources' availability for ESB call distribu- 
tion. Other methods my be used to ascertain agent avail- 
ability, including whether an agent is on a current call. 
The ESB workstation 620 may also access a customer 
database 615 that contains information related to cus- 
tomers and their transactions with the enterprise. 
[0073] A customer 607 places a call into the call cent- 
er 640 through the PSTN 101, and the call arrives at the 
IVR phone switch 610 and is connected to the IVR port 
associated with the IVR application 601 . The IVR phone 
switch 610 interacts with the customer while communi- 
cating the arrival of the call via the WAN 636 to the ESB 
workstation 620. The ESB application 611 then exam- 
ines the call to determine its pertinent characteristics 
and may also retrieve data from the customer database 
615 in performing its analysis. The ESB application 611 
also constructs a workpacket containing relevant items 
for the resource (e.g., an agent) who will process the 
call. The workpacket may comprise appropriate infor- 
mation retrieved from the caller via the PSTN 101 , the 
IVR 61 0 and from the customer database 615. The ESB 
application 611 assigns attributes to the workpacket 
consistent with this particular customer interaction and 
consistent with the skills stored in the staff database 604 
for processing the call. 



[0074] The work pushers 61 8, 61 9 on each Work Sta- 
tion 605 ; 606 updates the staff database 604 regarding 
availability, where availability for this illustration is simply 
"Available to be pushed work from the ESB" or "Not 
5 Available to be pushed work," Other methods may be 
used for notification to the ESB such as work pushers 
directly interacting with the ESB or the ESB directly in- 
teracting with the work pushers or any other means by 
which a work pushers status can be known. 
[0075] If there is no further customer interaction with 
the IVR 610 and the call may be distributed to an agent 
at either the workstation 605 or the workstation 606, 
then the call remains parked at the VRU 610 and the 
ESB application 611 makes the workpacket available to 
any Work Pusher 618, 619. Note that no interaction is 
actually required between the IVR 610 and the customer 
607. Also the interaction may be a simple request for 
the customer's identification code such as might be re- 
quested by even a PBX or a PC based switching system. 
[0076] Assume that an agent associated with the 
workstation 605 then becomes available and the Work 
Pusher 618 requests a workpacket appropriate for this 
agent's skill set. The ESB application 611 identifies the 
workpacket to the Work Pusher 618. The Work Pusher 
618 then requests the workpacket from the ESB appli- 
cation 611. The ESB application 611 then sends the 
workpacket corresponding to the call being held at the 
IVR 610 to the Work Pusher 618. 
[0077] The Work Pusher 618 opens the workpacket 
and retrieves the address of the IVR application 601 as- 
sociated with the call on the IVR 610 and requests the 
IVR application 601 to transfer the call to the phone 
number for its associated phoneset 607. The phone 
number may be a simple number or it may be a set of 
instructions to traverse telephony network equipment to 
reach the phoneset 607. The IVR application 601 ac- 
knowledges the successful transfer of the call to the 
Work Pusher 618. While waiting for the call to arrive, the 
Work Pusher 618 delivers the workpacket data to the 
workstation application to allow this application to pro- 
vide a "screen pop" on the workstation 605. The "screen 
pop" provides customer information and may also guide 
the agent in the handling of the call. Upon arrival of the 
call at the phoneset 607 the Work Pusher 61 8 will inform 
the IVR application 601 of the call arrival. 
[0078] This set of actions completes the distribution 
of the customer 607 to a resource represented by work- 
station 605 that is available and has the skills to handle 
this customer request. Note that the above scenario 
works in a similar manner should the agent represented 
by the Work Pusher 61 9 in the geographic site 634 have 
been requested the call before Work Pusher 61 8. If both 
the Work Pushers 618, 61 9 had been both available but 
not equally qualified; then the ESB application 611 
would select between the two Work Pushers based on 
their associated agent skills and the ESB application's 
knowledge of other outstanding requests for agent 
skills. All else being equal, the ESB application 61 1 may 
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select the Work Pusher 618 over the Work Pusher 619 
because the Work Pusher 618 has been the most idle 
agent, or the least occupied agent. In any event, a call 
arriving at either the IVR 610, 612 can be distributed to 
any agent in either geographic center 632, 634 via the 
PSTN 101 and WAN 636. 

[0079] As previously discussed, in some embodi- 
ments of the invention, the Work Pusher module may 
transfer the workpacket to an agent workstation 605 
while retaining the call at the VRU 610, allowing the se- 
lected resource to decide whether to perform the work 
in the workpacket or return the workpacket to the ESB 
application 61 1 for processing by another enterprise re- 
source. For example, the ESB application 611 moves 
the workpacket to the Work Pusher 618. The agent at 
the agent workstation 605 reviews the workpacket and 
decides whether to process the customer call. If the 
agent decides to process the customer call, and pro- 
vides a call-processing indication to the Work Pusher 
618, then the Work Pusher application 61 8 sends a call- 
transfer notice to the IVR application 601. The Work 
Pusher 618 sends back to the IVR application 601 a 
phone number for the agent telephone 607 associated 
with the agent workstation 605. The IVR 610 then trans- 
fers the call to the telephone 607 using the telephone 
number provided by the Work Pusher 618 Once the call 
has been transferred, the VRU application 601 notifies 
the Work Pusher 618 of the call's transfer. If the agent 
determines to not process the customer call, and pro- 
vides a call-processing indication to the Work Pusher 
618, then the Work Pusher 618 sends a notification to 
the ESB application 611 that it is not processing the call. 
The Work Pusher 61 8 may then request additional work. 
The ESB 611 application will then distribute the work- 
packet for this call to some other Work Pusher or other 
agent that may not have an associated Work Pusher. 
[0080] The call center 640 may also transfer calls to 
a telephone 644. The telephone 644 represents an en- 
terprise resource that is not equipped to interact with a 
workflow system such as the agent workstations 605, 
606. That is, a workstation 641 associated with tele- 
phone 644 has no capability to directly manipulate work- 
packets in a high-speed production environment such 
as is associated with call center agents. This lack of 
functionality may be a function of the specific worksta- 
tion capabilities associated with the telephone 644 or 
the location of the workstation 641 . such as a remote 
employee working from home. Such enterprise resourc- 
es may typically be found in the employee resources 
404 shown in Figure 4. The call center 640 may provide 
additional functionality for providing workpackets to the 
enterprise resource associated with the telephone 644. 
If the call is to be directed to the telephone 644, the ESB 
application 611 may seek out alternative routes for 
transferring the workpacket to the employee resource 
associated with the telephone 644. For example, the 
ESB application 611 may construct an e-mail message 
to the workstation 641 associated with the employee re- 



source at the telephone 644 that informs the employee 
resource of the location for the workpacket. The ESB 
application 611 may even bundle the workpacket with 
the e-mail message. This alternative communication 
5 means with the workstation associated with telephone 
644 may be provided by a conventional workflow system 
whose capabilities include using an e-mail channel for 
moving workpackets. 

[0081] The ESB implementation for the call center 

10 640 using the ESB application 611 and the Work Push- 
ers 618, 619 is but one possible design for associating 
work with a call and pushing the work and call to the 
agent workstations 605, 606 and the agent phonesets 
607, 608. The ESB implementation for the call center 

15 640 is a connected model where all clients are connect- 
ed over a data network to the ESB application 611 and 
does not specify any particular means for establishing 
connections or interchanging or messages across a 
connection. An exemplary implementation for providing 

20 connectionless models where connections are made 
and broken based on the need for participation, such as 
might be made by a more centralized ESB application 
611 . and using object oriented techniques that includes 
agent-to-agent transfer of calls outside of the ESB ap- 

25 plication is disclosed in U.S. Patent Application No., 
09/235,065 "Call Center Telephone and Data Flow Con- 
nection System," filed on January 21 , 1 999, assigned to 
the Mosaix Corporation, and which is incorporated here- 
in by reference. 

30 [0082] Figure 7 illustrates exemplary ESB selection 
criteria 701 that provide data for enabling an embodi- 
ment of the enterprise service balancer 401 to deter- 
mine the precise enterprise resource to receive a call. 
The enterprise service balancer examines the ESB se- 

35 lection criteria set 701 . ESB sources 702 provide the da- 
ta in the ESB selection criteria set 701 and may include 
a customer database 703, an IVR data set 704, and call 
data 705. The call data 705 comprises intrinsic informa- 
tion that may be automatically retrieved from a tele- 

40 phone call without requiring any operation on the part of 
the caller, such as the caller's phone number (ANI), the 
number they called (DNIS for "800" numbers), the type 
of location from which they are calling (II digits provide 
phone booth, prison, etc.), or may include Customer En- 

45 tered Digits ("CED") which the customer may have en- 
tered by request of a network service. The IVR data set 
704 represents information gathered from the caller via 
some type of querying mechanism {e.g., a menu). The 
customer database 703 represents data derived from a 

50 call database that includes data related to both the caller 
and the enterprise's resources. The ESB sources 702 
may include additional ESB sources and may also in- 
clude fewer ESB sources. 

[0083] The ESB selection criteria set 701 provides a 
55 data template that may be consulted by the enterprise 
service balancer 401 in determining the appropriate re- 
source to receive a customer call. Exemplary ESB se- 
lection criteria in the ESB selection criteria set 701 in- 



13 



25 



EP 1 035 718 A1 



26 



elude the telephone number called (for example, a par- 
ticular call center client's 800 number), the caller's tele- 
phone number (that may be used to retrieve customer- 
related data), Customer Entered Digits, the call's time 
of arrival, the caller's location (determined either from 
the caller's telephone number, the 800 number or from 
a customer database), the caller's account number the 
caller's account status, the caller's requested transac- 
tion, options selected by the caller, the service level cat- 
egory to be associated with this caller on this transaction 
{e.g., Platinum customer class), the call's urgency, the 
last agent contacted by the caller, the caller's security 
information, the caller's past transaction data, the call- 
er's preferences (which may be obtained from both the 
customer database and by querying the client), the call- 
er's present disposition (which may be determined from 
the IVR 704), and a prior agent assessment regarding 
the caller. 

[0084] Since an enterprise may alter its ESB selection 
criteria, the ESB selection criteria set 701 may contain 
different criteria than those presently shown. Moreover, 
the ESB selection criteria set 701 may contain additional 
items or even fewer items than shown here. The enter- 
prise may alter and re-configure the ESB selection cri- 
teria set 701, and the enterprise may operate different 
ESB selection criteria for different operations within the 
enterprise. For example, different 800 numbers may 
have different ESB selection criteria associated with 
them. Similarly, the enterprise may consult with a differ- 
ent set of items from its ESB sources 702. 
[0085] The enterprise service balancer may deter- 
mine that not all of the items in the data template of the 
ESB selection criteria set 701 have a corresponding ref- 
erence provided by the ESB sources 702 for a particular 
customer call. Accordingly, the enterprise service bal- 
ancer may be constructed to select a resource for a call 
on the basis of less information about the call than its 
ESB selection criteria set 701 indicates. 
[0086] The enterprise service balancer may also uti- 
lize data related to its resources, such as its call center 
agents, in matching a call with the most appropriate en- 
terprise resource. Figure 8 illustrates a representative 
ESB agent table 800 that contains the type of data that 
an enterprise may wish to collect regarding its call center 
agents and then reference when selecting an appropri- 
ate resource for a call. The enterprise may utilize a dif- 
ferent data set, and the enterprise may construct similar 
tables for its other resources. 

[0087] The ESB agent table 800 contains criteria that 
may be utilized by embodiments of the enterprise serv- 
ice balancer in determining an appropriate agent to re- 
ceive a customer call. The ESB agent table 800 may 
include an agent's qualified capabilities to service cus- 
tomers. These capabilities can be described as skills 
(types of work that are worked on by the enterprise), 
preferences (the ranking of skills for an agent), and skill 
rating (the capability of an agent to perform this skill). 
An agent may have a capabilities rating that represents 



a range of calls that the agent may receive based upon 
the difficulty of the tasks associated with the call, e.g., 
loan processing might be rated at as having a prefer- 
ence of "8" while checking the status of a check re-order 

5 might be rated as a "1 ." Given two calls available to this 
agent, of these two types (and all other factors being 
equal) ; the agent will take the loan processing call un- 
less the ESB determines that the check re-order call 
should be taken to meet service levels. 

10 [0088] The ESB agent table 800 may also contain an 
optimal service capabilities, or optimal skills level, for a 
particular agent. For example, the enterprise service 
balancer 401 will generally not distribute simple calls to 
agents having a higher than necessary degree of skills, 

15 but will instead route such calls to agents having a lower 
level of skills that is still high enough to satisfy the call's 
requirements. Aside from other pertinent assignment 
criteria, the enterprise service balancer will generally as- 
sign a call to the agent having the lowest acceptable skill 

20 level required for processing a given call. However dur- 
ing certain peak service periods ; the enterprise service 
balancer may need to select any agent capable of re- 
sponding to the call, such as an agent with a higher than 
necessary skill level. 

25 [0089] In some circumstances, the most appropriate 
agent to receive a call is the agent who last dealt with 
the caller. Accordingly, the ESB agent table 800 will also 
contain agent identification information and retain infor- 
mation related to calls recently processed by the agent. 

30 [0090] An enterprise may be associated with various 
clients, as well as having enterprise subsidiaries, and 
the enterprise service table 800 also contains a listing 
of the clients, or subsidiaries, for which the agent may 
process calls. The enterprise service table 800 may also 

35 contain statistical information related to the speed with 
which the agent statistically can process workpackets 
for different skill types or client types. Such information 
allows the enterprise service balancer 401 to determine 
whether a particular agent will be occupied too long with 

40 the task associated with a given call. Collected from 
within the entire enterprise, such information allows the 
enterprise service balancer to determine whether opti- 
mal service levels should be utilized or whether qualified 
service levels should be utilized. 

45 [0091] In addition, some embodiments of the enter- 
prise service balancer may select one agent over an- 
other similarly qualified agent based on the agents' oc- 
cupancy and how close each agent will be toward reach- 
ing the their occupancy if the agent receives the call. 

50 Occupancy is the percent of time agents are on calls. 
Exceeding 90% can lead to agent burnout which leads 
to agent's becoming less efficient in their work. Some 
designers of the ESB agent table 800 may not wish to 
mix real-time information {e.g., agent occupancy infor- 
ms mation) with static information. In some embodiments, 
a separate real-time data table 801 may be included that 
is updated with a variety of information provided by the 
enterprise service balancer. Of course, in other embod- 
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iments, the real-time data table 801 may be included 
within the ESB agent table 800. 
[0092] Finally, the ESB agent table 800 may also con- 
tain information related to particular agent privileges, 
such as being allowed to directly receive telephone 
calls. The enterprise service balancer 401 may alter the 
availability of such privileges based upon the total call 
load within the enterprise at a given period of time. For 
example, during a peak period within the enterprise, 
agents may lose the privilege of receiving direct tele- 
phone calls (to their Agent DN) since their help is need- 
ed urgently in processing calls ; according to an embod- 
iment of the invention. 

[0093] An exemplary method and system for estab- 
lishing preference values and threshold values for serv- 
ice classes related to work items, such as may be uti- 
lized in the ESB agent table 800 and the enterprise serv- 
ice balancer 401 , is disclosed in U.S. Patent Application 
No. 09/149,877, "Dynamically Assigning Priorities for 
the Allocation of Server Resources to Competing Class- 
es of Work Based Upon Achievement of Service Level 
Goals," filed on September 8, 1998, assigned to the Mo- 
saix Corporation, and which is incorporated herein by 
reference. 

[0094] Additionally, embodiments of the present in- 
vention may also operate in conjunction with a method 
and system for adjusting the availability of resources (a 
g., agents) for performing various types of work. An ex- 
emplary method and system for adjusting the availability 
of resources for performing various types of work is dis- 
closed in U.S. Patent Application No. 09/247,893, "Dy- 
namically Allocating Server Resources to Competing 
Classes of Work Based Upon Achievement of Service 
Level Goals," filed on February 10, 1999 ; assigned to 
the Mosaix Corporation; and which is incorporated here- 
in by reference. 

[0095] In addition ; the present invention may also op- 
erate in conjunction with an exemplary method and sys- 
tem for computing a dynamic component in a composite 
preference value associated with a work item. An exem- 
plary method and system for computing a dynamic com- 
ponent in a composite preference value is disclosed in 
U.S. Patent Application No. 09/248,047, "Hierarchical 
Service Level Remediation for Competing Classes 
Based Upon Achievement of Service Level Goals ; " filed 
on February 10, 1999, assigned to the Mosaix Corpora- 
tion, and which is incorporated herein by reference. 
[0096] Figure 9 provides further details regarding 
workpackets transferred to enterprise resources. Work- 
packets comprise data that the enterprise service bal- 
ancer 401 has determined may be appropriate for the 
processing of a call. The data associated with the work- 
packet may be appropriately supplemented by the re- 
sources; such as an agent, through applications availa- 
ble to the resource, such as a call-handling application 
at an agent workstation. Accordingly, workpackets may 
have various sizes and will not all necessarily contain 
the same information. Figure 9 illustrates two workpack- 



ets, a workpacket 901 and a workpacket 902, being sent 
to call center agents from the enterprise service balanc- 
er. 

[0097] The workpacket 901 contains a set of caller da- 
5 ta 903, a database link 904, client catalog protocols 905, 
and a call pointer 908. The call pointer 908 may be uti- 
lized in accessing the call associated with the workpack- 
et 901 . The client catalog protocols 905 may include a 
client catalog that may be helpful to the agent selected 
to process the call. The client catalog protocols 905 may 
be an expanded version of a client catalog that includes 
information not necessarily available to callers, such as 
links to warehouse data. The client catalog protocols 
905 may also contain a client special instruction wizard 
907 that contains special instructions for the agent in 
processing the call. 

[0098] The workpacket 902 contains the caller data 
903, the database link 904, a past transaction record 
906, and the call pointer 908. The past transaction 
record 906 may be useful to the agent in answering the 
customer's call. For example, the workpacket 902 may 
be applicable in the processing of a customer call relat- 
ed to the status of an order. 

[0099] Figure 10 illustrates the linking of workpackets 
in a call parking facility utilized by the enterprise service 
balancer 401 while attempting to find an appropriate re- 
source to process the call represented by the workpack- 
et; according to an embodiment of the invention. An ex- 
emplary enterprise service balancer may have a varia- 
ble number of associated parked calls at any given mo- 
ment. For example, an enterprise service balancer may 
have workpackets 1001, 1002, 1003, and 1004. Each 
of the workpackets 1001-1004 has an associated call 
pointer 908 that may be used to retrieve the call asso- 
ciated with the workpacket. The workpackets also each 
have a resource identifier 1005. The resource identifier 
1005 is usually incomplete while the enterprise service 
balancer 401 searches a set of appropriate resources 
representing the enterprise to process the call. If the en- 
terprise service balancer 401 locates an available re- 
source suitable for processing the work packet, then the 
enterprise service balancer 401 provides the identity of 
the resource in the resource identifier 1005. If the enter- 
prise service balancer 401 has identified a specific re- 
source that is not instantly available, but should be avail- 
able within a configurable time period, then the resource 
identifier 1005 may contain an identifierforthe resource. 
If the timeout expires, then an alternative resource will 
be selected by the enterprise service balancer 401 . 
[0100] The workpackets 1001-1004 may be linked to 
each other in a worklist 1000, as shown in Figure 10, 
but do not necessarily need to be processed by the en- 
terprise service balancer 401 in the order that they have 
been received. It is expected that there will be many dif- 
ferent types of calls each type with different service re- 
quirements, and it is the arrival of agents to service 
these calls, each agent with different servicing capabil- 
ities, that determines the order in which calls will be dis- 
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tributed. Accordingly, it is unlikely this will be a First In 
First Out ("FIFO") distribution of calls except in the sim- 
plest of cases. In addition, the workpackets do not nec- 
essarily need to be kept in a linked list but may be or- 
ganized in another data structure. 
[0101] Figure 11 illustrates an exemplary agent work- 
station 1110 for processing workpackets, according to 
an embodiment of the invention. Resources, such as 
agents, will interact with the enterprise service balanc- 
ing system via an ESB client application in the agent's 
workstation, such as Work Pusher applications 61 8, 619 
shown in Figure 6. The ESB client application may even 
be provided to the resource using a browser application. 
The ESB client application may either be a thin client or 
a fat client. A thin client comprises a small application 
that retrieves much of its processing capabilities from a 
server while a fat client contains greater processing ca- 
pabilities. Implementing the ESB client application as a 
browser application somewhat blurs the distinction be- 
tween thin and fat clients. The agent workstation 1110 
includes a computer 1103 having a GUI application 
1 1 06, a telephone 1 1 02 and an agent head set 11 01 . 
[0102] When an ACD agent becomes available, the 
agent typically actuates a ready button 1 1 07 on the GUI 
application 1 1 06 using a mouse 1 1 09 or actuates a sim- 
ilar button on a desktop keyboard 1108. In the enterprise 
service balancing system 410, this agent action triggers 
a request to the enterprise service balancing system to 
provide the next workpacket. The enterprise service bal- 
ancing system - based on the achievement of current 
service levels across the enterprise and which - if any - 
work can be handled by this call center agent - will then 
send a workpacket to the ESB client application asso- 
ciated with the agent's workstation 1110. The workpack- 
et represents the best work for this agent to perform at 
this time, as determined by the enterprise service bal- 
ancing system. If the agent actuates a retrieve call but- 
ton 1104, the ESB client application will then make a 
request to the enterprise service balancing system to 
have the call directed to the headset 1101 Of course, 
the delivery of the call to the headset may be configured 
within the ESB application to be coincidental with the 
opening of the workpacket to obtain the parking address 
of the call and transfer the call to the headset 1101. 
[0103] The enterprise service balancer allows a re- 
source, such as the call center agent, to preview a work- 
packet without necessitating a connection to an associ- 
ated call (or other work item). Because the agent's own 
application controls delivery of the call, the agent can 
preview a "screen pop" 1111 of customer information 
and decide whether to take the call or transfer it else- 
where using a transfer call button 1105. The resource 
may be performing other work at the time the workpack- 
et arrives and decide to send the workpacket back to be 
distributed to another enterprise resource. The ability to 
decline workpackets may be especially helpful to back- 
office agents who perhaps do not normally handle calls 
and may wish to accept only selected calls. The transfer 



call button 1 1 05 may also initiate transfer of a customer 
call to another resource within the enterprise. For exam- 
ple, the resource at the agent workstation 1110 may dis- 
cover during processing of the call that the call would 

5 be better processed by another resource within the en- 
terprise. Accordingly by actuating the transfer call but- 
ton 1105, the resource may place the customer call at 
precisely the best location with the enterprise for further 
processing. In the preferred embodiment the transfer 

10 sends a notification to the enterprise service balancer 
401 to redistribute the call since the agent's knowledge 
of the best resource may be incomplete. 
[0104] The ESB client application interacts with the 
GUI application 1106 to provide the workpacket screen 

15 pop 1111 to the resou rce. The initial screen pop may not 
necessarily contain all of the information in the work- 
packet fully displayed. The additional information may 
be retrieved by the resource as necessary. For example, 
the workpacket may contain other media references 

20 such as optical images. When the resource accesses a 
work item in a workpacket, the work item may be moved 
(or opened) and presented to the resource. 
[0105] In typical CTI event-driven implementations, 
the CTI event arrives and triggers a "screen pop," while 

25 atthe same timethe ACD/PBX(orasimilarly functioning 
switch) performs an uncontrolled delivery of the call to 
the agent's headset. Having two separate systems pro- 
vide the two items needed by the agent, the customer 
information associated with the screen pop and the call 

30 itself, creates a race condition between the screen pop 
and the call arrival that necessitates some system for 
synchronizing the screen pop and the call arrival. The 
enterprise service balancer 401 eliminates this race 
condition by directing that the workpacket's arrival occur 

35 prior to sending the call to the agent's headset 1101, 
according to an embodiment of the invention. 
[0106] The agent (resource) may retrieve a specific 
parked call for continued processing by actuating the re- 
trieve call button 1104, as previously discussed. In one 

40 embodiment, the agent may actuate the retrieve call but- 
ton 1 1 04 by using either a combination of hot keys or by 
clicking on the retrieve call button 1104 using a cursor 
controlled by the mouse 1109. In another embodiment, 
the computer 1103 may be provided with a touch-sen- 

45 sitive screen and the agent may simply touch the re- 
trieve call button 1 1 04. By actuating the retrieve call but- 
ton 1104, the agent initiates continued processing of a 
parked call. 

[0107] In some embodiments, parked calls may be 
50 parked at a remote location. In the preferred embodi- 
ment, parked calls are simply redirected to the telepho- 
ny device 1 1 02 at the agent workstation 1110. This call 
transfer occurs through the enterprise service balanc- 
er's work pusher {e.g., the work pusher 410 shown in 
55 Figure 4) that supplies the telephony device address to 
the call parking component at the remote location. In 
other embodiments, the retrieval process utilizes a cen- 
tralized ESB application that incorporates this work 
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pusher function to move the parked call to the agent 
workstation 1 1 1 0, as would occur for the telephone 644 
in Figure 6. 

[0108] Figure 12 illustrates additional information that 
may be retrieved in an exemplary workpacket 1200 
processed by an enterprise resource. The exemplary 
workpacket 1200 includes the customer's name, the 
customer's telephone number, the customer's account 
number, and the customer's level of service. The work- 
packet 1200 also indicates that the customer has been 
secured. Security may be provided by requiring the cus- 
tomer to enter a code, for example, and may be satisfied 
by automated processing before the call reaches the 
agent. The workpacket 1200 also identifies the client 
and relevant information regarding the client, such as a 
corporate motto. 

[0109] The workpacket 1200 also indicates the urgen- 
cy of the call. The workpacket 1 200 may further indicate 
when the call arrived, the present time, and the amount 
of time that the caller has been waiting. The workpacket 
1 200 may also indicate the customer's last order, its sta- 
tus, and additional relevant information, such as an 
identification of the agent who processed the customer's 
last order. The workpacket 1200 may also provide the 
agent with the caller's preferences. 
[0110] Figures 13A and 13B comprise a flowchart 
1 300 illustrating the processing of a call in an enterprise 
service balancing system 410 utilizing an enterprise 
service balancer 401, according to an embodiment of 
the invention. 

[0111] The enterprise service balancer 401 receives 
a call (step 1301 ). The enterprise service balancer an- 
alyzes the call and begins composing a workpacket 
(such as shown in Figure 12) that contains pertinent in- 
formation about the call (step 1303). Based upon its 
analysis of the call ; the enterprise service balancer de- 
termines the pertinent call properties (step 1305). The 
pertinent call properties may include data such as that 
shown in the ESB selection criteria set 701 shown in 
Figure 7. The enterprise service balancer may add 
some of the pertinent call properties to the workpacket. 
The enterprise service balancer determines whether da- 
tabase data should be retrieved for further determina- 
tion of pertinent call properties (step 1307). If the enter- 
prise service balancer determines that database data 
should be consulted in determining the disposition of the 
call (step 1 307), then the enterprise service balancer re- 
trieves the appropriate data from a database (step 
1309). The enterprise service balancer may add some, 
or all, of the data from the database to the workpacket. 
The enterprise service balancer then analyzes the da- 
tabase data associated with the previously identified 
and pertinent call properties (step 1311). 
[01 1 2] Based upon the information that it has received 
thus far, the enterprise service balancer 401 then se- 
lects an appropriate enterprise resource to dispose of 
the call (step 1 313). If database data is not necessary 
(step 1307), then the enterprise service balancer 401 



proceeds to step 1 313. In selecting an appropriate en- 
terprise resource, the enterprise service balancer may 
consult data such as that shown in the ESB selection 
criteria table 702 shown in Figure 7 and may also ana- 
s lyze pertinent information regarding resources such as 
the ESB agent table 800 shown in Figure 8 For example, 
this database may contain information regarding the re- 
al-time availability of resources. The enterprise service 
balancer then determines the best available call-receiv- 
ing resource (step 1315) and sends the workpacket to 
the selected call-receiving resource (step 1317). If no 
such resources are available (step 1315), the call will 
continue to be parked until such a resource becomes 
available As previously discussed, the initial screen pop 
associated with a workpacket's arrival at the resource's 
workstation may comprise a smaller subset of data than 
the complete workpacket itself. 

[011 3] While waiting for a resource to become avail- 
able, and if this call is more important than other calls 
vying for the appropriate resource, then the enterprise 
service balancer may determine to expand the number 
of resources that are appropriate to handle this call (step 
1319). The enterprise service balancer may determine 
to expand the number of resources that are appropriate 
to service this call, including non-human resources such 
as IVR resources or Voice-Mail for self-servicing. The 
enterprise service balancer 401 determines the scope 
of resources based on all competing calls and or other 
competing work and the manner in which to either in- 
crease or even decrease the number of resources avail- 
able to service the call. This evaluation may include ac- 
quiring additional information from a number of different 
resources and including the customer via an IVR com- 
munication. An exemplary method and system for dy- 
namically managing the scope of resources within an 
enterprise environment is disclosed in U.S. Patent Ap- 
plication No. 09/247,893, "Dynamically Allocating Serv- 
er Resources to Competing Classes of Work Based Up- 
on Achievement of Service Level Goals ; " filed on Feb- 
ruary 10, 1999, assigned tothe Mosaix Corporation, and 
which has been previously incorporated herein by ref- 
erence. Once such an evaluation has completed , the 
processing returns to Step 1 31 5. An ordinarily skilled ar- 
tisan will recognize that this is a description of a process 
using a flowchart and that the step 1 31 9 may occur in- 
dependently and concurrently with Step 1315. 
[011 4] Once the selected call-receiving resource has 
received the workpacket, the call-receiving resource 
may examine the workpacket to determine if the re- 
source will provide further processing of the workpacket 
or its associated customer call. If the call-receiving re- 
source elects to process the workpacket, then the call 
may be transferred to telephony equipment associated 
with the call-receiving resource. 

[0115] Figure 14 illustrates an exemplary enterprise 
service balancing system 1410 that processes custom- 
er communications arriving from a variety of media, ac- 
cording to an embodiment of the invention. As previous- 
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ly discussed, the enterprise service balancing system is 
not limited merely to processing customer communica- 
tions arriving from a telephony medium. Customer com- 
munications may arrive from a variety of media, such as 
telephony, e-mail, Internet telephony, Internet commu- 
nications, video kiosk, and other forms of video stream- 
ing applications. 

[0116] The enterprise service balancing system 1410 
comprises an enterprise service balancer 1401, com- 
munication processing applications 1402-1406, and a 
database 1407. The communication processing appli- 
cations 1402-1406 may comprise call-handling and 
Work Pusher applications such as those shown in Fig- 
ures 5 and 6, as well as Figure 1 1 . The communication 
processing applications 1402-1406 may operate with 
work pushers, with one or more conventional ACDs, or 
with othersimilarfunctioning equipment. The ellipsis be- 
tween the communication processing application 1405 
and the communication processing application 1406 in- 
dicates that the enterprise service balancing system 
1401 may comprise more communication processing 
applications than shown in Figure 14. 
[0117] The enterprise service balancer 1401 receives 
customer communications from a variety of media as 
shown. The ellipsis between medium 3 and medium 4 
indicates that the enterprise service balancer may proc- 
ess customer communications received from more than 
four different mediums. Of course, the enterprise serv- 
ice balancer 1401 may also process customer commu- 
nications received from a smaller number of communi- 
cation media. 

[0118] The enterprise service balancer 1401 receives 
customer communications and processes the customer 
communications in a manner similar to that discussed 
with regard to the other embodiments of the enterprise 
service balancer. However, the enterprise service bal- 
ancer 1401 has additional capacity for selecting an ap- 
propriate resource to process a customer communica- 
tion on the basis of the medium from which the customer 
communication arrived in the enterprise service balanc- 
ing system 1410. For example, the enterprise service 
balancer 1401 may direct that an e-mail customer com- 
munication, which is not an interactive communication, 
be processed differently by the communication process- 
ing applications 1402-1406 than a customer communi- 
cation that is interactive, such as one arriving from te- 
lephony or video streaming. The enterprise service bal- 
ancer 1401 may extract and analyze customer and re- 
source data from the database 1 407 as appropriate. 
[0119] From the foregoing it will be appreciated that, 
although specific embodiments of the invention have 
been described herein for purposes of illustration, vari- 
ous modifications may be made without deviating from 
the spirit and scope of the invention. Accordingly, the 
invention is not limited except as by the appended 
claims. 

[0120] While the present invention has been de- 
scribed with reference to preferred embodiments there- 



of, those skilled in the art will appreciate that various 
changes in form and detail may be made without depart- 
ing from the intended scope of the present invention as 
defined in the appended claims. For example, the ele- 
5 ments associated with the enterprise service balancer, 
and the workstations may differ from those shown in the 
figures, and enterprise service balancer applications as- 
sociated with the enterprise service balancer (e.g., a 
Work Pusher) might be provided to support various ad- 
10 ditional functions. Workstation applications in addition 
to being interacted with by a human may also be inter- 
acted with by a robotic application. Accordingly, embod- 
iments of the invention are applicable to call centers 
staffed entirely with human agents, call centers having 
15 hybrid robotic and human agent workstations, and call 
centers having completely robotic applications. 
[0121] The enterprise service balancer may be run on 
different types of computing systems or on computing 
systems differing substantially from the enterprise serv- 
20 ice balancing system discussed herein. In addition, the 
elements associated with the enterprise service balanc- 
er within a given call center may each operate on a dif- 
ferent type of computing system provided that the en- 
terprise service balancer ultimately performs the tasks 
25 described herein. Elements of the enterprise service 
balancer modules may be provided in microcode in a 
hardware device, such as that provided on a computer 
chip or an application specific integrated circuit 
("ASIC"). Elements of the enterprise service balancer 
30 may also be invoked through a specialized call center 
telephone such that selection, or actuation, of a button 
on the specialized call center telephone initiates opera- 
tion between the telephone and the enterprise service 
balancer. Other equipment associated with embodi- 
es ments of the enterprise service balancing system may 
also be provided in microcode in hardware devices, 
such as a computer chip or an ASIC. For example, the 
enterprise service balancer itself may be comprised of 
one or more ASICs in one or more call centers that com- 
40 municate with each other in such a manner so as to pro- 
vide the functionality described herein. 
[0122] In one exemplary alternative embodiment, the 
enterprise service balancer may be provided as a plug- 
in device at a call center. In this embodiment, a utility 
45 program could be run in the call center to appropriately 
configure the call center for operations with the plug-in 
device. Such a device would operate in all significant 
respects in the same manner as the embodiments de- 
scribed herein. In another embodiment of the invention, 
50 the enterprise service balancer may be merged into an 
ACD/PBX. The enterprise service balancer may be pro- 
grammed in any programming language. The enterprise 
service balancer may interface with CTI middleware 
products, as such IBM Callpath, Genesys T-Server, or 
55 Dialogic CT-Connect. 

[0123] The enterprise service balancer may be con- 
figured to operate with a variety of call-directing devices. 
In addition, an initialization program may operate in con- 



25 



30 



35 



40 



45 



50 



18 



35 



EP 1 035 718 A1 



36 



nection with the resources in the enterprise and the en- 
terprise service balancer to enter the site-specific infor- 
mation, such as the Agent DNs for the agents within a 
call center and the Phone DNs for the call center tele- 
phones. The initialization program may also allow logi- 
cal functions, like the Agent DNs, to be matched to phys- 
ical functions like the Phone DNs. In some instances, 
there may only be Phone DNs, and the agent's personal 
data network identification, such as a workstation login 
supplants the Agent ID. The initialization program may 
further assign the appropriate calling scripts for the rout- 
ing points. 

[0124] In one embodiment the enterprise service bal- 
ancer 506 utilizes the ACD 102 to distribute calls to 
agents while managing service levels for calls and for 
all other channels such as e-mail, fulfillment {e.g., re- 
search a billing inquiry), and fax as in 1402. The enter- 
prise service balancer 506 may control ACD call distri- 
bution by making agents 120 available or not -available 
to receive calls through control of the agent's ACD state, 
either through 1st or 3rd party call control means. With 
this control means an agent is always in the ACD "NOT 
READY to take a call from the ACD" ACD state unless 
the enterprise service balancer 506 determines that the 
best work for this agent is to take an ACD 102 distributed 
call. To receive an ACD 102 distributed call, the agent 
1 20 is placed into a "READY to take a call from the ACD" 
ACD state by the enterprise service balancer 506 and 
the agent will receive a call from the ACD 102. The calls 
being distributed may either be parked at an ESB route 
point 502, 504 and are redirected by the ESB 506 to a 
ACD Skill/Split Hunt Group 1 06, 1 07 at the time an agent 
is made available or after calls are processed by the 
ESB application 506, the calls are simply parked 
(queued by the ACD) at ACD Skill/Split Hunt groups 
106, 107 waiting for an agent logged into one or more 
ACD Skill/Split Hunt groups to become READY. In either 
implementation, it is the ESB 506 that controls the dis- 
tribution of calls to an agent 120. If an ACD call is not 
the best work at this time for this agent, then the agent 
will receive some other non-ACD work. This exemplifies 
that even an ACD 102 can be treated as a switching 
system and can be controlled by the enterprise service 
balancer 506. 

[0125] The enterprise service balancing system may 
also produce an event log of the customer communica- 
tions and workpackets transferred to one or more enter- 
prise resources. The log data may be stored in a data 
repository associated with the resource or may be 
stored in a remote database. The log may be examined 
by appropriate supervisory personnel to ensure that the 
enterprise services balancing system is functioning 
within expected parameters. 

[0126] If a caller hangs up while the enterprise service 
balancer is either attempting to locate an appropriate re- 
source or is in the process of transferring the call to the 
selected resource, a telephony sub-system {e.g., a CTI 
link) may notify the enterprise service balancer of this 



event through a call disconnected message. The enter- 
prise service balancer then removes the workpacket 
from consideration for call delivery but then forwards the 
workpacket for further processing by the workflow sys- 
5 tern {e.g., for Platinum callers, place the call in a priority 
call back worklist). 

[0127] In yet another embodiment, the enterprise 
service balancer may direct a blind transfer of a call to 
an enterprise resource. A blind transfer is a call transfer 
in which the transferor indicates a transfer location for 
a call without checking whether the new transferred lo- 
cation is available. For example, in a conventional tele- 
phone system, a caller is typically placed on hold, then 
the transferor dials a telephone number and hits a trans- 
fer button which initiates an automatic transfer of the 
call. A blind transfer contrasts with a supervised transfer 
in which the transferor actually verifies that the trans- 
ferred number is available before the call is transferred. 
A blind transfer might be used by the enterprise service 
balancer to queue a call to a specific resource such as 
a hunt group robotic resources like IVR ports. 
[0128] Although specific embodiments of, and exam- 
ples for, the invention are described herein for illustra- 
tive purposes, various equivalent modifications are pos- 
sible within the scope of the invention, as will be recog- 
nized by those skilled in the relevant art. The teachings 
provided herein of the invention can be applied to other 
enterprise communication systems, not necessarily the 
exemplary enterprise communication system described 
above. Various exemplary computing systems, and ac- 
cordingly; various other system configurations can be 
employed under the invention. 

[0129] The embodiments of the invention disclosed 
herein have been discussed with regard to enterprise 
communications systems ; such as those using large 
computing systems. However, the invention finds appli- 
cability in other computing systems, such as small, port- 
able computerized systems and even decentralized 
computing devices distributed in a network. The enter- 
prise service balancer may be utilized for transferring 
data only, calls only, or even other types of connections. 



Claims 

1 . A method for processing communications in a com- 
munication-processing system that comprises a 
plurality of communication-processing centers 
(403-405) each comprising a plurality of communi- 
cation-processing resources (406-409), each with 
a communication-processing resources set 
(800-801 ) that includes a description of the commu- 
nication-processing resource, CHARACTERISED 
BY 

receiving (1 301 ) a communication into the com- 
munication-processing system; 
analyzing (1 303) the communication at a SerV- 
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ice balancer (401 ;506) that serves the plurality 
of communication-processing centers of to cre- 
ate (1305) a communication properties set 
(701); 

selecting (1 31 3) at the service balancer a com- s 
munication-processing resource of any one of 
the plurality of communication-processing 
centers by comparing the communication prop- 
erties set against the communication-process- 
ing resources set that includes a description of 10 
the communication-processing resource of at 
least some of the communication-processing 
resources of a plurality of the communication- 
processing centers; and 

sending (1317) a new work indicator (901 ;902) is 
from the service balancer to the selected com- 
munication-processing resource. 

2. The method of claim 1 wherein: 

20 

sending a new work indicator comprises 
creating (1 303-1 309) a new work indicator that 
represents the communication and includes a 
link (908) to a call-parking application 
(502,504) that holds the communication until 25 
the communication is transferred to a commu- 
nication-processing resource; 
accessing (1104) the call-parking application 
from the new work indicator by the selected 
communications-processing resource; 30 
receiving a transfer request at the call-parking 
application from the selected communication- 
processing resource; and 
transferring (41 0) the communication to the se- 
lected call-processing resource by the ac- 35 
cessed call-parking application. 

3. The method of claim 1 wherein: 

sending a new work indicator comprises creat- 40 
ing (1 303-1 309) a new work indicator that con- 
tains information pertaining to the communica- 
tion; and the method further comprises 
examining (1111) the new work indicator at the 
selected communications-processing resource 45 
to select whether to process the new work indi- 
cator by the selected communications- 
processing resource; 

engaging at least one communications- 
processing application (618;619) to process so 
the new work indicator if new work indicator 
processing is selected (1104); 
receiving the communication associated with 
the new work indicator by the selected commu- 
nications-processing resource if new work indi- 55 
cator processing is selected (1104); and 
sending a work declined indication to the serv- 
ice balancer if examination of the new work in- 



dicator results in selecting not to process the 
new work indicator. 

4. The method of claim 1 wherein the communication 
is received into the communication processing sys- 
tem at a first communication processing center 
(403), further comprising: 

transferring the communication to the select- 
ed communication-processing resource in a sec- 
ond communication processing center (405). 

5. The method of claim 1 wherein: 

receiving a communication comprises 
receiving the communication into the service 
balancer. 

6. A system (401 ) for processing communications re- 
ceived by a communications-processing system 
(400) that comprises a plurality of communication- 
processing centers (403-405) each comprising a 
plurality of communications-processing resources 
(406-409), each with a communication-processing 
resources set (800-801) that includes a description 
of the communication-processing resource, CHAR- 
ACTERISED BY 

a communications receiver (401 or403) that re- 
ceives communications; 
an enterprise service balancer (401 ;506) that 
serves the plurality of communication-process- 
ing centers and that includes 

a receiver that receives (1301) a commu- 
nication notification from the at least one 
communication receiver pertaining to a re- 
ceived communication, 
an analyzer that analyzes (1303) the re- 
ceived communication to compose (1305) 
a communication properties set (701) for 
the received communication, and 
a comparator that selects (1 31 3) a commu- 
nications-processing resource of any one 
of the plurality of communications- 
processing centers to process the commu- 
nication by comparing the communication 
properties set with the communication- 
processing resources set that includes a 
description of the communication-process- 
ing resources of at least some of the com- 
munication-processing resources of a plu- 
rality of the communication-processing 
centers; and 

a transmitter that sends (131 7) a new work in- 
dicator (901;902) to the selected communica- 
tion-processing resource. 
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7. The system of claim 6 wherein: 

the enterprise service balancer provides a link 
(908) in the new work indicator to a call-parking ap- 
plication (502,504) that holds the communication 
until the communication is transferred to a commu- s 
nication-processing resource in response to the 
call-parking application receiving a transfer re- 
quest. 

8. The system of claim 6 wherein: 10 

the at least one communications receiver re- 
sides and receives the communication at a first 
communication-processing center (403); and 
the selected communication-processing re- 15 
source resides and receives the received com- 
munication from the at least one communica- 
tion receiver at a second communication- 
processing center (405). 

20 

9. The system of claim 6 further comprising: 

a work pusher (41 0-41 2) operatively connect- 
ed to the enterprise service balancer that directs the 
transfer of at least one of the received communica- 
tion and the new work indicator corresponding to 25 
the received communication to the selected com- 
munications-processing resource. 

10. The system of claim 9 wherein: 

30 

the work pusher comprises 
a first communications link (636) for transmis- 
sion of the new work indicator; 
a second communications link (101,636) for 
transmission of any associated media with the ss 
customer communication; 
a receiver (618,619) configured to receive a 
transfer request from the selected communica- 
tions-processing resource that includes the se- 
lected resource's addresses on the first and 40 
second communication links, to establish a 
second communications link with the selected 
communications-processing resource, to 
transfer the new work indicator to the selected 
communications-processing resource over the 45 
first communications link, and to transfer any 
associated media over the second communica- 
tions link. 
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